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INTRODUCTION 



I . 



A . BACKGROUND 

Cost estimation of software is one of the few areas in the 
computer industry that has not progressed with the rapid 
technological advances and growth experienced by the remainder 
of the computer industry. Although extensive studies have 
been completed and many cost estimation models developed, 
there is still no evidence that the software industry can 
accurately estimate the cost of a software project. Cost 
overruns, late deliveries, poor reliability, and user 
dissatisfaction has created an atmosphere of distrust in cost 
estimation models. In a recent speech, for example, Air 
Force General Bernard Randolph characterized software as the 
"Achilles' heel of weapons development" and continued later 
stating, "On software schedules, we've got a perfect record; 
We haven't met one yet . " (Kitf ield, 1989, p. 29) A report from 
the 101ST Congress summarized, "that in an increasingly 
constrained budget environment greater controls must be 
established to alleviate the continual cost overruns and 
excessive cast growth of these systems ." (Congress, 1989, pp. 
1-2) In order to contend with these problems, cost estimation 
studies were directed toward the understanding of the complete 
software development process, which included many management 
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issues . Although some progress has been made in the 
understanding of this development process, the problems still 
tend to persist. Studies have discovered that this, so 
called, "Software Monster" is as much a managerial problem as 
a technical one (Schlender, 1989, p. 100) . Meanwhile, the 
demand for more reliable and more sophisticated software 
continues to escalate with the increased dependence of 
computers in everyday life (Abdel-Hamid, 1989, p. 1426) . 

Coupling an algorithmic model, such as a Constructive Cost 
Model (COCOMO) , and a Systems Dynamics Simulation Model of 
Software Project Management may enhance the ability to provide 
better cost estimations. A coupled computer based modeling 
system can be used to efficiently and effectively study the 
effects of altering various objective and subjective 
management controlled variables on the cost and schedule 
aspects of a software project. The modeling system can also 
be used to repeat the same project simulation many times while 
adjusting different parameters in an effort to determine the 
variables that are most sensitive to the cost and schedule of 
a single project. 

Many organizations today utilize a matrix organizational 
structure. 'In this type of organizational structure many 
resources are shared by several different projects. The 
coupled modeling system can create a means to simulate two 
projects in a shared resource environment that automatically 
refines the cost and schedule estimates. It can also repeat 
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the simulation process many times while adjusting different 
parameters not only to achieve optimization in estimation, but 
also to determine the variables most sensitive to cost and 
schedule estimates in a two project environment. 

B . OBJECTIVES 

Several models have been developed to provide cost 
estimates for software development projects. The COCOMO model 
has been one of the most widely studied and used models in 
cost estimation. The System Dynamics Simulation Model of 
software development has been developed to study the effects 
of certain management policies on software project 
development. These management polices are subjective in 
nature and are difficult to define. The emphasis of this 
thesis will focus on the development of a new kind of software 
estimation model that combines an algorithmic model, COCOMO, 
with a systems dynamic simulation model . It will initially 
focus on single software development projects, but will also 
include studies considering cost estimation in a two project 
environment. Additionally, this thesis will investigate the 
addition of management variables as a means to enrich the 
current set of COCOMO cost drivers . The test cases presented 
will be proofs to ensure proper operation of the interfaces 
between models. The experiment presented will be that of 
limiting one specific resource variable between the two 
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projects and observing the process of automatic refinement of 
cost estimates over a series of iterations. 

C. THE RESEARCH QUESTION 

The primary research question of this thesis is to 
determine the advantages of coupling COCOMO with a dynamic 
simulation model of software development. The other important 
question of this thesis is whether the combined model would 
enhance our ability to do sensitivity analysis and to 
determine what, if any, approach is best for optimizing cost 
estimations in a two project environment. 

D . SCOPE 

The scope of this thesis is to analyze the usefulness of 
the composite model concept, and to investigate the utility 
gained from coupling these two models in both the single and 
two project environments. The scope of this thesis is not, 
however, to improve cost accuracy. 

E . METHODOLOGY 

This thesis follows a series of logical steps in the 
development and testing of a coupled modeling system. The 
initial phase consists of designing a small "C" test program 
to determine the best possible interface between the program 
and the simulation model. Once an interface is successful, 
the second phase begins. It includes the development of a "C" 
program which will operate as a front-end system for the 
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simulation model and provide the COCOMO cost estimations for 
effort and schedule. After completion of the program and the 
interface is successful, testing must occur. The testing 
includes baseline tests of program algorithms to ensure the 
data being passed between programs is accurate. This phase of 
testing includes testing the Basic COCOMO Model, the 
Intermediate COCOMO Model, and nominal productivity 
calculations . 

The last phase includes the programming and testing of two 
additional "C" programs. The first program is very similar to 
the program previously developed. It also includes the front- 
end system and the COCOMO cost estimations for effort and 
schedule. The difference between the programs is that the 
program from the previous phase was developed for a single 
project environment and the latter provides for the same 
requirements in the two project environment. After successful 
completion of this program, a back-end program will be 
developed to evaluate the results, provide adjustments where 
necessary, and create an automatic iterative loop process 
which continually refines cost estimations. 

The testing for this phase will include a simple test, as 
above, to prove the accuracy of program algorithms, but will 
also include an experiment. The experiment will consist of 
several tests to determine the opportunity gained by creating 
an iterative loop process for refinement of cost estimations 
in a two project environment. In addition, it will also test 
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the ability of this type of modeling system to do extensive 
sensitivity analysis by limiting certain shared variables and 
observing the results under several different conditions. 

F. ORGANIZATION OF STUDY 

This chapter has discussed the general background and 
themes which direct this study. The remaining chapters are 
organized as follows. Chapter II discusses the architecture 
of the system. This includes background discussions on the 
dynamic simulation model, COCOMO and the design structure of 
the integration between the two models. Chapter III describes 
in-depth the operation of the system. Chapter IV discusses 
the tests and experiments conducted in this thesis. The tests 
will show the validity of the program algorithms and the 
experiment will show the potential of using this coupled 
modeling system. Chapter V discusses the conclusions and 
recommendations attained from conducting this study. 
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II. SYSTEM ARCHITECTURE 



A. INTRODUCTION 

This system is a coupling of a series of "C" programs and 
a dynamic simulation model to create an interactive, user- 
friendly support tool for the purpose of studying and refining 
cost estimation procedures while gaining a better 
understanding of software development project management. 
This chapter first discusses the background of the dynamic 
simulation model and COCOMO . It then discusses, in detail, 
the system integration between the two models. 

B. A DYNAMIC SIMULATION MODEL OF SOFTWARE DEVELOPMENT 

The Dynamic Simulation Model is part of an on going study 
of software development project management dynamics. The 
model focuses on four basic subsystems which integrate the 
management process of software development as well as the 
production-type functions that constitute the software 
development life cycle (Abdel-Hamid, 1990, p. 21) . The four 
subsystems include: human resource management; software 
production; controlling; and planning. The Dynamic Simulation 
Model is unique in that it is able to integrate key management 
related software development processes such as scheduling, 
productivity, and staffing to derive implications and gain 
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knowledge about behavioral aspects of management in the 
overall software development process. It is also unique in 
its use of the feedback principles of system dynamics to 
structure and clarify the complex web of dynamically 
interacting variables. Figure 2-1 establishes the 
interactions and relationships between each of the four 
subsystems (Agan, 1990, p. 7) . 

The human resource management subsystem comprises the 
hiring, training, assimilation, and transfer of the human 
resource. In this subsystem, the work force is divided into 
two types of employees, newly hired and experienced. Newly 
added team members tend to be less productive than experienced 
members. On the other hand, experienced members productivity 
is reduced due to the training needs involved in assimilating 
newly added members into the team. Employee turnover also 
directly impacts project development. The larger the project 
the greater the turnover rate. This corresponds with the 
above productivity discussion of newly added members being 
less productive . (Abdel-Hamid, 1990, p.22) 

Figure 2—1 suggests "work force available" has a direct 
bearing on the allocation of manpower among the different 
software production activities in the Software Production 
Subsystem. The primary software production activities are 
development, quality assurance, rework and testing. 
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Figure 2-1 : Four Sub-systems of the Dynamic 
Simulation Model 

Quality assurance is used as a means of detecting errors 
in development activities. Although some errors will elude 
detection until the testing phase, errors detected through 
quality assurance will be reworked. As progress is made, a 
comparison of where the project is versus where it should be 
is evaluated. This evaluation is a function of the control 
activity in the Controlling Subsystem. Since software is an 
intangible product during most of the development process and 
there are no visible milestones to measure progress or 
quality, the' Controlling Subsystem contains some of the most 
difficult problems a manager must solve. Therefore, the 
Controlling Subsystem possibly has the greatest impact on this 
entire system. As depicted in Figure 2-1, the Controlling 
Subsystem directly effects the Planning Subsystem in the 
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quantification of "effort remaining" which indirectly impacts 
both "schedule" and "work force needed" to complete the 
project. The "progress status" of the project reported back 
to the human resource management subsystem directly effects 
team productivity. In early stages of the project, team 
members rely on the managers assessment of their overall 
productivity as they are unable to perceive the productiveness 
of the work force. Therefore, as the project nears 
completion, the managers projected productivity gradually 
ceases to influence the perceived productivity of the team as 
it becomes a function of feedback determined by actual tasks 
completed. (Abdel-Hamid, 1990, p. 23) 

The Planning Subsystem is responsible for the initial 
project estimates and, when necessary, the revised estimates 
as each subsystem continues to effect the other until project 
completion. For example, for a project perceived to be behind 
schedule, a manager may hire additional employees, delay the 
schedule, possibly a combination of the two, or do nothing 
(Abdel-Hamid, 1990, p. 23) . 

The dynamic simulation environment of this model 
concentrates on the managerial aspects of software development 
and on the fundamental understanding of the software 
development process. 
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C . COCOMO MODEL 



The Constructive COst MOdel or COCOMO is an algorithmic 
model that is used to determine initial cost estimates in 
software development effort and schedule. Initial cost 

estimates of this model are a function of the estimated size 
of the software product in source instructions. There are 
three different versions of COCOMO which include Basic COCOMO, 
Intermediate COCOMO, and Detailed COCOMO. Basic COCOMO is an 
algorithmic model that is effective for quick and rough order 
of magnitude estimates of software costs. However, its 

accuracy is limited because it does not account for 
differences in hardware constraints, personnel quality and 
experience, use of modern tools and techniques, and other 
project attributes known to have a significant impact on 
software costs. (Boehm, 1981, p. 58) 

The intermediate COCOMO model increases the accuracy of 
basic COCOMO by incorporating 15 cost drivers into the effort 
and schedule calculations. These 15 cost drivers are grouped 
into four categories: software product attributes, computer 

attributes, personnel attributes, and project attributes. The 
cost drivers are listed by category below: 

• Product "Attributes 

- Required Software 

- Reliability 

- Database Size 

- Product Complexity 
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• Computer Attributes 

- Execution Time Constraint 

- Main Storage Constraint 

- Virtual Machine Volatility 

- Computer Turnaround Time 

• Personnel Attributes 

- Analyst Capability 

- Applications Experience 

- Programmer Capability 

- Virtual Machine Experience 

- Programming Language Experience 

• Project Attributes 

- Modern Programming Practices 

- Use of Software Tools 

- Required Development Schedule 

Each of these cost drivers has an associated multiplying 
factor used in the algorithmic calculations to determine, with 
more accuracy, the overall effort and schedule costs of the 
software development pro ject . (Boehm, 1981, pp . 114-117) 

The detailed version of COCOMO employs a three level 
hierarchical decomposition of the software product whose cost 
is to be estimated (Boehm, 1981, p. 347) . It also uses effort 
multipliers to determine the phase distribution of effort over 
the life cycle. This version of COCOMO did not lend itself to 
this coupled modeling system and, therefore, was not utilized. 

In the COCOMO environment there are three modes of 
software development. They include the Organic Mode, the 
Semidetached Mode, and the Embedded Mode. Distinguishing 
between the modes is extremely important to prevent 
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overestimation or underestimation in the amount of effort 



required for the project. (Boehm, 1984, p. 20) 

The organic mode represents projects with relatively small 
software teams who operate in a familiar, in-house 
environment. The teams are comprised of people with extensive 
experience in the organizations structure, in working with 
related systems, and in understanding how the system will 
contribute to the goals and objectives of the organization. 
The Organic mode environment lends itself to a relatively 
relaxed atmosphere that leads to higher productivity and 
smaller diseconomy of scale on the project. (Boehm, 1981, p. 
78) 

The semidetached mode represents a project that falls 
between the definition of the organic mode and the embedded 
mode. The software project development teams are comprised of 
a wide mixture of experienced and inexperienced people, some 
of which understand how the system relates to the organization 
and some that do not. (Boehm, 1981, p. 79) 

The embedded mode represents a project which must operate 
in a strongly coupled complex of hardware, software, 
regulations and operational procedures. Initially, the team 
consists of "a small group of analysts, normally from outside 
the organization, who complete product design. Then, again 
from outside the organization, a large group of programmers 
are hired to complete the project. Because of rigid 
requirements and the inability to make changes to these 
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requirements, the embedded mode environment tends to be less 
productive and lead to greater diseconomies of scale . (Boehm, 
1981, pp. 78-80) 

D. INTERFACING "C" PROGRAMS WITH DYNAMIC SIMULATION MODEL 

Interfacing between programs is accomplished through the 
DOS operating system. DOS uses a series of system calls to 
maneuver through the different processes within the batch 
files. The DOS operating environment allows the system, 
through the use of errorlevel calls and goto statements, to 
execute and exit the different programs which are not 
compatible due to software language limitations (Schildt, 
1988, pp. 140-143) . 

Figure 2-2 represents a model of the total system 
architecture which indicates the flows and controls of the 
execution process of all the programs which makeup the coupled 
model. The batch file, RUN. BAT is executed by typing RUN at 
the DOS prompt and pressing enter. This batch file 
initializes the start up of the coupled model. Once the 
system is initialized, the user must select the project 
environment in which to operate. The batch file RUN. BAT first 
calls the "C" program called MAIN.EXE as shown in Figure 2-2. 
It is a small program that allows user access into either the 
single project or two project environment. Figure 2-2 clearly 
illustrates the distinct paths of the two environments. After 
the decision is made, the model automatically executes the 
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selected INPUT program. The INPUT program is used as a front- 
end system for the dynamic simulation model and as an 
algorithmic model to complete the COCOMO calculations. 



★ *****★*★*★★★****★***★*★* RUN . BAT **************************** 



/* This is tha main batch file which initiates the */ 

/* execution of the coupled modeling system. */ 

6 ECHO OFF 

del report . out 

main 

/* In the "C" language , the exit command with */ 

/* an associated number, such as exit(l), enables */ 
/* DOS's ERRORLEVEL command to accept the exit */ 
number, (1) in this case, and call the next */ 
appropriate program using a GOTO statement. */ 
Several examples of this are shown in RUN. BAT, */ 
the batch file displayed below. The remainder */ 
of the M C n programs all interface with the DOS */ 
batch environment in the same manner. 

IF ERRORLEVEL 1 GOTO two 
input 1 /* 

GOTO done 



/* 

/* 

/* 

/* 

/* 

/* 



/* single project environment */ 

GOTO disp 
GOTO prn 
GOTO done 



if exit 

IF ERRORLEVEL 1 
GOTO roll 
: roll 

call execl.bat 
output 1 

IF ERRORLEVEL 4 
IF ERRORLEVEL 3 
IF ERRORLEVEL 0 
GOTO done 
: two 
input 2 

IF ERRORLEVEL 1 GOTO done 
GOTO run 
: run 

call exec2.bat 
IF ERRORLEVEL 1 
output 2 

IF ERRORLEVEL 4 
IF ERRORLEVEL 3 
IF ERRORLEVEL 1 
IF ERRORLEVEL 0 
:disp 

type report . out 
GOTO done 
: prn 

print report . out 
GOTO done 
: done 

REM Program operation is complete. 



(0) , then execute */ 



/* two project environment */ 
GOTO done 

GOTO disp 
GOTO prn 
GOTO run 
GOTO done 

/* display on screen */ 



/* print results */ 



************************************************************* 
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After the inputs and calculation are completed, the 
program automatically terminates, and the appropriate EXEC 
batch file is called. The process of interfacing the program 
to the batch file is discussed in the documentation portion of 
the RUN. BAT source code displayed below and throughout the 
source code of the actual programs included in the Appendices . 
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Figure 2-2: 



Complete 



System Architecture 
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1. SINGLE PROJECT ENVIRONMENT 



Figure 2-4 represents the processes and data flows 
within the system architecture that occur in the single 
project environment. 

The single project environment is entered by user 
selection from a menu which is displayed in Figure 2-3. 



INITIALIZATION OF PROGRAMS 
(Select one of the following) 

1 - SINGLE Project Environment 

2 - TWO Project Environment 

Select environment you wish to use and press enter: 



Figure 2-3: INITIALIZATION OF PROGRAMS MENU 

Once selected, INPUT1.EXE, a "C" program designed to interface 
with a single project environment version of the dynamic 
simulation model, is executed. The INPUT1.EXE program enables 
the user to utilize current parameters from a saved project, 
change parameters from a previously saved project or 
completely enter a new project. INPUT1.EXE has two basic 
functions. The first is to complete COCOMO cost estimation 
calculations from the input variables entered by the user. 
The second is to provide a front end system that allows the 
user to easily input or provide changes to the input variables 
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Figure 

Project 




2-4 : Coupled Model Architecture for a Single 

Environment 
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of the dynamic simulation model. Once the inputs and 
calculations are completed the entire list of variables are 
saved to a file called SIMONE. DNX, which is displayed in the 
input/output file below. 



*********************** * SIMONE .DNX************************** 



/* This an example of the output file created by */ 

/* INPUT1.EXE and is the input for the simulation. */ 

C RJBDSI=64000 
C TOTMDl=4113 . 23 
C TDEV1=302 . 60 
C INUDST= 0.50 
C ADMPPS= 1.00 
C HIREDY=40.00 
C AVEMPT=1000000 . 00 
C TRPNHR= 0.20 
C ASIMDY=80.00 

T TNERPK=25.00 23.86 21.59 15.90 13.60 12.50 
T TPFMQA=0 . 150 0.150 0.150 0.150 0.150 0.150 
0.150 0.150 0.150 0.150 
C DEVPRT= 0.80 
C DSIPTK=55 . 22 

*********************************************************** 



OUTFILE . DNX is a binary file which is also saved at 
this point in the process. This file is utilized in 
conjunction with 0UTPUT1.EXE. This file passes COCOMO 
estimated effort and schedule costs to the 0UTPUT1.EXE program 
for report processing. This file was developed to easily pass 
variables directly from INPUT1.EXE to 0UTPUT1.EXE while 
keeping them completely separate from the dynamic simulation 
model. After the files are saved, INPUT1.EXE automatically 
terminates and returns to the DOS environment to call 
EXEC1.BAT which initiates the dynamic simulation environment 
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project. This batch file works identical to the main batch 

file in regard to the interfacing between programs and 

processes of the dynamic simulation model. The batch file is 

shown below and is modeled as an insert in Figure 2-4. 

★ a************************ EXEC 1 . BAT **************************** 

/* This batch file represents the batch file that calls */ 

/* the simulation model for the single project environment. */ 



DYNEX SIMONE -d model. drs 
IF ERRORLEVEL 4 GOTO ERROR 
SMLT SIMONE -GO = — DTM = 

REP SIMONE -T 
GOTO EXIT 
: ERROR 

ECHO *** ERROR 1 **** 

:EXIT 

*************************************************************** 



DYNEX.EXE, SMLT.EXE, and REP . EXE are executable 
programs which are programmed in the dynamo language and must 
be present in the default directory for the System Dynamics 
Model to operate. The SIMONE. DRS file, displayed below, is 
used by the dynamo report generator to write the required 
output which will be displayed in SIMONE. OUT. 



*********************** **SIMONE . DRS************************* * 

/* This file works in conjunction with the dynex program */ 
/* and the dynamo report generator to produce the output */ 
/* file SIMONE. OUT. */ 

REPORT 

TIME=MAXTIME, 

FORMAT="l<, 15>, 16< n , PICTURE="ZZZZZZV. 99 n 
" cuxEBod ( " , CTJMMD , " ) . n 

FORMAT= n l<, 15>, 16<" , PICTURE= n ZZZZZZV. 99" 
n time ( ” , TIME, n ) . n 

************************************************************* 
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SIMONE. DNX, as discussed above and as shown in Figure 
2-4, is the output file of INPUT1.EXE and contains all of the 
input variables used by the simulation model. Figure 2-4 also 
depicts the relationships of the primary components of the 
dynamic simulation model and how they relate to both the 
EXEC1.BAT and RUN. BAT batch files. 

Upon completion of the dynamic simulation model and 
EXEC1.BAT, the system again returns to the RUN. BAT batch file 
where 0UTPUT1.EXE is called. This program utilizes 
information from OUTFILE.DNX and SIMONE. OUT to allow the user 
the ability to print or display the comparisons between the 
estimates and actual costs of effort and schedule. The 
results are saved to a file called REPORT . OUT . This file 
will remain resident on disk until the program is re- 
initialized . 

2. TWO PROJECT ENVIRONMENT 

Figure 2-5 represents the processes and data flows 
within the system architecture that occur in the two project 
environment. The two project environment is entered by user 
selection from a menu which is displayed after execution of 
MAIN.EXE and is shown in Figure 2-4. Once selected, 
INPUT2.EXE, a "C" program designed to interface with a two 
project environment version of the dynamic simulation model, 
is executed. The INPUT2.EXE program enables the user to 
utilize current parameters from saved projects, change 
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Figure 2-5: 
Environment 



System Architecture for Two Project 
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parameters from previously saved projects or completely enter 
new projects to complete two basic functions. The first is to 
complete COCOMO cost estimation calculations from input 
variables entered by the user for both projects, as discussed, 
in the previous section. The second is to provide a front end 
system that allows the user to easily input or provide changes 
to the input variables for both projects in the dynamic 
simulation model. Once the COCOMO calculations and inputs are 
completed and the variables entered, the entire list of 
variables are saved to a file called SIMTWO.DNX, which is 
displayed in the input/output file below. 



********************** *s IMTWO . D NX** *********************** ** 



/* This an example of the output file created by * / 

/* INPUT2.EXE and is the input for the simulation. */ 

C RJBDSI (1)=64000 
C RJBDSI (2) =64000 
C TOTMD1 (1) = 3593 
C T0TMD1 (2) = 3593 
C TDEV1 (1) = 348 

C TDEV1 (2) = 348 

C INUDST (1) = 0.50 
C INUDST (2) = 0.50 
C ADMPPS (1) = 1.00 
C ADMPPS (2) = 1.00 
C HIREDY (1) =40 . 00 
C HIREDY (2) =40. 00 
C AVEMPT(l) =1000000. 00 
C AVEMPT (2) =1000000. 00 



c 


TRPNHR (1) = 0. 


.20 














c 


TRPNHR (2) = 0. 


.20 














c 


ASIMDY ( 1 ) =80 . 


.00 














c 


ASIMDY (2) =80 . 


.00 














T 


TNERP1=25 . 00 


23.86 


21.59 


15.90 


13 


. 60 


12 


.50 


T 


TNERP2=25 . 00 


23.86 


21.59 


15.90 


13 


.60 


12 


.50 


T 


TPFMQ1=0 . 150 


0.150 


0.150 


0.150 


0 . 


150 


0 . 


150 




0.150 


0.150 


0.150 


0.150 


0 








T 


TPFMQ2=0 . 150 


0.150 


0.150 


0.150 


0 . 


150 


0 . 


150 




0.150 


0.150 


0.150 


0.150 


0 









C DEVPRT (1) = 0.80 
C DEVPRT (2) = 0.80 
C DSIPTK (1) =59 . 89 
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C DSIPTK (2) =59 . 89 
C STRTDT (1) = 0.00 
C STRTDT (2) = 0.00 
C Nd.TWT=1000000 . 00 

******************************************************** 

OUTFILE2.DNX is a binary file which is also saved at 
this point in the process. This file is utilized in 

conjunction with OUTPUT2.EXE. This file passes COCOMO 
estimated effort and schedule costs to the OUTPUT2.EXE program 
for report processing and iterative loop control. The file 
was developed as a means to easily pass variables directly 
from INPUT2.EXE to 0UTPUT2.EXE while keeping them completely 
separate from the dynamic simulation model process. After the 
files are saved, INPUT2.EXE automatically terminates and 
returns to the DOS environment to call EXEC2.BAT. This 
initiates the dynamic simulation environment for two projects. 
The batch file works identical to the main batch file and 
EXEC1.BAT in regard to the interfacing between programs and 
processes of the dynamic simulation model. EXEC2.BAT is 
displayed below and is modeled as an insert in Figure 2-5. 

★★★★★★★★★★★★★★★★★★★★★★★★EX EC2 . BAT*************************** 

/* This batch file represents the batch file that calls */ 

/* the simulation model for the two project environment. */ 



DYNEX SIMTWO -d model. drs 
IF ERRORLEVEL 4 GOTO ERROR 
SMLT SIMTWO -GO = — DTM = 

REP SIMTWO -T 
GOTO EXIT 
: ERROR 

ECHO *** ERROR 1 **** 

:EXIT 

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 
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DYNEX.EXE, SMLT.EXE, and REP . EXE are executable 
programs which are programmed in the dynamo language and must 
be present in the default directory for the System Dynamics 
Model to operate. The SIMTWO.DRS file, displayed below is 
used by the dynamo report generator to write the required 
output which will be displayed in SIMTWO.OUT. SIMTWO.DNX, as 
discussed above, is the output file of INPUT2.EXE and stores 
all of the input variables used by the simulation model. 
Figure 2-5 also depicts the relationships of the primary 
components of the dynamic simulation model and how they relate 
to both the EXEC2.BAT and RUN. BAT batch files. Upon 



***********************SXMTWO . DRS *** ****** ********** * *★* ***** 



/* This file works in conjunction with the dynex program */ 
/* and the dynamo report generator to produce the output */ 
/* file SIMONE. OUT. */ 

REPORT 

TIME=MAXTIME, 

FORMAT="l<, 15>, 16<" , PICTURE="ZZZZZZV. 99" 
n cummd ( " , CUMMD ( 1 ) , ") . " 

FORMAT= " 1< , 15>, 16<" , PICTURE="ZZZZZZV. 99" 

" cummd ( " , CUMMD ( 2 ) , ") 

FORMAT="l<, 15>, 1 6<" r PICTURE^" ZZZZZZV . 99" 

" time ( " r DURTN ( 1 ) , " ) . " 

FORMAT^" 1< , 15>, 16<", PICTURE="ZZZZZZV. 99" 

" time ( " , DURTN ( 2 ) , ") . " 

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ 



completion of the dynamic simulation model and EXEC2.BAT, the 
system again, returns to the DOS environment where 0UTPUT2.EXE 
is called. This program utilizes information from 
0UTFILE2 . DNX and SIMTWO.OUT to create an iterative loop 
environment . 



26 



Figure 2-5 shows the flow of the iterative loop 
process with dotted lines. The basic theory behind this 
process is to give the user the ability to decide on the 
accuracy level and the number of iterations to run in order to 
continually refine cost estimates. The iterative loop runs as 
many times as the user desires or until the error rates are 
equal to or less then those entered by the user. The error 
rates are determined by using standard algorithms for finding 
percent error (i.e., difference between estimated effort from 
COCOMO and actual effort determined by the simulation model 
divided by the actual effort) . In addition to loop 
limitation and error rate entries, the user may also wish to 
adjust the actual effort and schedule values determined by the 
simulation model prior to execution of the next loop. These 
adjustments can be made to both schedule and effort values in 
each of the two projects. 

The error rates, loop limitations, and adjustment 
factors give the user the flexibility to run the same projects 
under many different conditions. This iterative loop process 
provides the user with an automated tool for sensitivity 
analysis to gain a better understanding of the software 
development process and as a means to refine cost estimations. 
As depicted in Figure 2-5, exiting this process either returns 
you to the loop or to the report menu for displaying or 
printing of results from the REPORT. OUT file. 
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III. SYSTEM OPERATION 



A. BACKGROUND 

This system is a coupling of a series of "C" programs and 
a dynamic simulation model to create an interactive, user- 
friendly support tool for the purpose of studying and refining 
cost estimation procedures while gaining a better 
understanding of software development project management. 



B . SPECIAL FEATURES 

The following is a list of several special features and 
considerations which were incorporated into the design and 
development of this system. 

• User Friendly: This system was designed for those who 

have some experience in using COCOMO and the Dynamic 
Simulation Model. Although the system is designed for 
ease of use, the user must have a general understanding of 
the different variables and their associated acronyms in 
order to achieve effective and efficient data entry. 

• Menu Driven: This system uses a menu-driven structure 

that enables the user to recognize the options available 
at each level . The highest level menu is the program menu 
to select a specific environment (i.e., a one or two 
project environment) . Once an environment is selected, 
the associated function menu appears. This menu enables 
the user to enter new projects, read existing problems 
from disk, or exit the program. Several options also have 
associated sub-menus to help direct the user. 

• Easy Data Entry and Modification: This system enables the 

user to enter data from the keyboard or read stored data 
from disk. Entry formats are designed for easy entry or 
modification of input variables. 
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C . GETTING STARTED 



The required and optional hardware, software and 
peripherals necessary to operate this coupled modeling system 
include the following: 

• Required Equipment: This coupled modeling system is 

designed to run on an IBM personal computer or true IBM PC 
compatible computer with at least 25 6K bytes of memory; at 
least one high density disk drive; and DOS 3.3 version or 
higher . 

• Optional Equipment: This model supports the IBM enhanced 

graphics card, IBM color graphics card, IBM VGA card, and 
Hercules monochrome graphics card. It supports the IBM 
proprinter and true compatiables . A hard disk drive would 
improve the overall operation of the system. A math 
coprocessor is supported for the dynamic simulation model 
but is not required. 



D. GETTING THE SYSTEM READY FOR USE 

For ease of use, this system is contained on a single high 
density floppy diskette. This enables complete operation from 
almost any floppy drive system. For faster processing of the 
system, it is recommended to load and operate the system from 
the hard disk. This system automatically uses the default 
printer, unless you redirect the output, at the time of 
printing, to another printer. 

1 . Installing the Software on Your Hard Disk 

If you are familiar with a utility tool, you may wish 
to create a new directory and copy all files and programs on 
the diskette to the new directory. Otherwise, continue with 
the following general procedures. 
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a. When your screen displays the DOS prompt of the 
drive you wish to install the program, make a sub- 
directory using the DOS command ' MKDIR' . For 
example the sub-directory may be called DSMI for 
Dynamic Simulation Model Interface. 

b. Go to the new sub-directory using the DOS command 
'CD' . Then copy all files and programs from the 
diskette to this new sub-directory using the 
'COPY' command. 

2 . Installation with Hercules Monochrome Graphics Card 

a. Ensure the three files "INT10.COM", 
"HAFLDCOPY.COM", and "PRINTER. DEF" are copied from 
the diskette to your hard disk root directory. 

b. Add the line "INT10" to your AUTOEXEC.BAT file. 

c. Add the line "HARDCOPY" to your AUTOEXEC.BAT file. 

E. OPERATING THE SYSTEM 

Operating the system can be accomplished either by running 
the system from the high density floppy diskette or the hard 
disk. Standard procedures for system operation are as 
follows : 

1 . Operating the System from Diskette 

The following is a list of steps required to operate 
the model from a diskette . This system can run on a high 
density floppy drive system. 

a. Turn computer on if not already on. 

b. Insert diskette into disk drive and change the 
default drive to the disk drive which contains the 
diskette (i.e., if default drive is C then change 
it so DOS prompt reads, for example, 'A>') . 

c. At the prompt type 'RUN' and press the ENTER key. 

The system will be loaded and the initial menu 
will be displayed. Figure 3-1 shows the 

initialization menu. 
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2 . Operating the System from the Hard Disk 

After the computer is turned on, the interface of the 
software is designed as a hierarchy of menus and a series of 
data entry points. To execute the model, proceed with the 
following steps. At the prompt of the sub-directory you 
created on the hard drive, type the command 'RUN' and press 
enter. This will display the welcome screen shown in Figure 
3—1. Press any key to continue to the environment selection 



**************************************************** 

Welcome to the coupling of 
COCOMO and a SYSTEMS DYNAMICS MODEL 

**************************************************** 
Programmed by Richard W. Smith & Tarek K. Abdel-Hamid 

Press [ANY KEY] to continue... 

Figure 3-1 : Welcome Screen 

window similar to the one displayed in Figure 3-2 . Your 
selection will determine which environment you will operate 
in. Once selected you may not traverse from the single 
project environment to the two project environment nor vice 
versa. As mentioned above, this system provides a hierarchy 
of menus. Thus, when you make a menu selection, you move to 
a new menu either up or down the hierarchy of menus . 
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Therefore, whichever environment is chosen, the appropriate 
initial menu will be displayed similar to the one in 
Figure 3-3. 



INITIALIZATION OF PROGRAMS 
(Select one of the following) 

1 - SINGLE Project Environment 

2 — TWO Project Environment 

Select environment you wish to use and press enter : 



Figure 3-2: INITIALIZATION OF PROGRAMS MENU 

F. OPERATING IN THE SINGLE PROJECT ENVIRONMENT 

The single project environment is available to observe how 
a single project is affected by software development project 
management over the life of the project. It can be also used 
as a tool for sensitivity analysis in studies concerning the 
effects certain variables have on the development cycle. The 
baseline data for this model is stored in a data file called 
BASE.PRF, and provides the values for the SIMONE. DNX input 
file shown on page 23. Assuming that the COCOMO estimates are 
accurate, the dynamic simulation model was adjusted, using 
baseline data, for the purpose of achieving an error rate of 
less than one percent between the initial cost estimates from 
COCOMO and the actual results from the simulation model. When 
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